By David P

By David P. Friedlander

Consider a Career in Actuarial Software<= /o:p>

Looking f= or a change in direction? Software may be calling your name.

Half of my job as a chief actuary at a software company is to h= elp design software that complies with the Actuarial Standards of Practice= and the applicable laws and regulations. Then I have to make sure the end produ= ct is in accordance with the designs. The other half of my job is to train and support the software users.

Today, nearly all actuaries use computer software and most use software tools that are designed specifically for actuaries. Some are at least partly designed= by their fellow actuaries. However, actuaries are also frequently involved in = the design of software tools that are used mainly by non-actuaries. If you̵= 7;re an actuary who enjoys working with computers, this could be the career path= for you.

&= nbsp;

Communication Skills Are Key

My own firm is always looking for the few people who have that elusive combination of actuarial, communication, and technology skills that make it possible to work smoothly with both the technology who ac= tually develop the code and the clients who use it. For our company, those end users are employee benefits professionals. However, other software fir= ms that employ actuaries produce tools used by life insurance actuaries, casua= lty actuaries, underwriters, and others.

Those of us who work with software firms find ourselves both training and supporting the actuaries and actuarial assistants who use= the software. These people are usually well versed in actuarial principals= but often know very little about computers. We also need to provide design specifications to technology professionals who know far more than we do abo= ut computers but may not know the difference between an actuary and a mortuary. Therefore, we need all of the communications skills that a consul= ting actuary needs as well as an understanding of computers. <= /p>

In ord= er to communicate actuarial principals to technology professionals, we = need to have a very thorough understanding of those principals. It’s the s= ame kind of understanding required to pass actuarial examinations, althoug= h, unlike some other environments in which actuaries work, software firms usua= lly consider the quality of their work much more important than examination-bas= ed credentials when they judge their employees.

A soft= ware product has to anticipate many different scenarios, some of which probably = were not included in the limited number of questions that could be included= on an examination. For example, a product that calculates optional forms = of pension benefits has to account properly for the participant whose bene= ;fits are the regulatory maximum benefit under the normal form of payment but not under the selected optional form and vice versa. On the other hand, it also= has to account properly for the person whose benefit is so small that the option isn’t permitted at all, along with the vast majority of cases that fa= ll between these extremes.

As an actuary who has been in the software development environment for 30 years, I’ve witnessed incredible changes in the da= ta processing environment. In this field, the one thing that’s cert= ain is change, so one has to be very flexible.

In the 1970s, almost all actuarial software resided on mainframe computers, often the so-called super computers (far from “super” by 2005 standards) that were manufactured by the now defunct Control Data Corporation. In those days, programs were laboriously created on punch cards, one instruction per card, and woe to anyone who dro= pped one of those decks if the cards weren’t properly numbered!=

By the early 1980s, much of the software had migra= ted to mini-computers manufactured by other poorly remembered companies su= ch as Prime Computing and Digital Equipment Corporation. I still remember authorizing a purchase in 1982 for a 300 megabyte disk drive that was the s= ize of a desk, had a removable disk platter weighing more than 50 pounds, = and cost about $20,000. (Today, a $300 MP3 player has 100 times more disk space, fits in my shirt pocket, and weighs 4 ounces.)

Later in the 1980s, the tools appeared on DOS-based personal computers. Of course, personal computers still dominate today, although DOS is nearly forgotten and has been replaced by various versions of Windows. Each of these advances, along with the well-known chan= ges in the regulatory environment, has required that the software tools be larg= ely rewritten and, therefore, has created new opportunities for those of u= s in the software development field.

&= nbsp;

In add= ition to these changes, the tools themselves have become far more complex, so tha= t it now requires a team of technology professionals to write the actual code. By comparison, as recently as the 1980s, actuarial software firms were often staffed entirely by technology savvy actuaries and employed few or sometimes no technology professionals. In those days, all that was expected= of the tools was that they produce the correct answers. Output didn’= ;t need to be attractive because it was manually transcribed before deliv= ery to the end user and nobody expected results to arrive in less than an hour.=

Today, we expect instant results that can be conveyed to the end user and with almost no work to be done by the operator of the tool= s. We also expect everything to run remotely via the Internet. What all t= his means to actuaries who work at software firms is that we have to communicate our science to technology professionals instead of write code. Communi= cations skills have become more important to us than programming skills. =

None of this means that anyone can work at a software environment without understanding data processing. We still have to know ho= w to write programming specifications that are acceptable to technology professionals, and this requires an understanding of database technology. Modern databases are accessed using a tool called SQL (sometimes pronounces as Sequel) and it’s very helpful for actuaries in this env= ironment to know that tool. It’s also very useful to be able to read and “debug” actual code and even to be able to write small patches = of that code (often referred to as “entry point programming”).

B= reaking the Code=

Progra= mming code is written using tools called programming language, so these skills require a familiarity with those tools. The most modern code is written in = the following languages: C++, C# (pronounced C-Sharp), D= ELPHI, Visual BASIC, and FORTRAN. However, we often also have to work with older c= ode that can be more economically maintained than rewritten. This code is also written in FORTRAN, BASIC (the predecessor of Visual BASIC) and PASCAL (the predecessor of DELPHI). However, it= may also be written in dying languages such as COBOL and APL, so it’s use= ful to know those too.

It’s also worth noting that the majority of actua= ries who work in software development companies are either enrolled actuari= es or associates of the Society of Actuaries or the Casualty Actuarial Soci&sh= y;ety, rather than fellows of those organizations. Because it’s one of = the areas in which an actuary can work without passing as many examination= s, the extra time we spend learning about computers may be at least partially offset by fewer hours of formal studying.

To summarize, working at a software company is a choice to consider if you’re a strong technical actuary with excellent communications skills, you’re able to deal with frequent changes to t= he environment in which you work, and if you enjoy working with computers and = know more about them than most of your fellow actuaries. It’s an option th= at may not require completing all of the fellowship examinations if you have techn= ical strengths that offset a lack of credentials.

&nbs= p;

David P. Friedlander is principal and chief actuary at Lynchval Systems Worldwide in Chantilly= , Va.